Re: vCard RDF compromises

Bruce D'Arcus wrote:
>
> I'm still confused about this,though. To be concrete, how would your
> suggestion deal with  names like "John Stuart Mill" (one v:givenName
> property or two?) or "Gabriel García Márquez" (one v:familyName
> property or two?)?
>

First, let me say that I have always assumed that the vCard "additional 
names" property was the preferred way to represent middle names. 
Therefore I'd expect N.givenName="John", N.familyName="Mill", and 
N.additionalNames=["Stuart"] (where [] denotes rdf:List; apparently too 
much Ajax programming is imprinting JSON on my brain...).

We should consider two scenarios: one in which the data is entered by 
the user, and the other in which data is imported from text/directory 
vCard. In the former scenario, I'd imagine that the user would be 
presented with three text inputs (in the en-US locale, that is): "First 
Name", "Middle Name", and "Last Name". Perhaps a button marked "Add More 
Middle Names...". The user could enter their name however they felt best 
represented it semantically, and the entry would be mapped to 
N.givenName, N.additionalNames, and N.familyName, respectively.

As for converting from existing vCard data, we could either let 
processors handle that how they choose, or we could require processors 
to follow a rule such as the following: 1. Set N.givenName to the first 
"given name" value. 2. Set N.familyName to the last "family name" value. 
3. Set N.additionalNames to the concatenated list of any remaining given 
names, any additional names, and any remaining family names, in that order.

The non-English names that include a concatenation of many family names 
("bin X bin Y bin Z" in Arabic for instance) are more interesting cases. 
I'd be content for the moment to simply allow the user to enter such 
information how they choose (i.e. as "additional names" or a single 
"family name"); we can provide suggestions later when there are more 
implementations in the wild that give us feedback on the best way to do 
this, but my suggested compromise would provide the flexibility to do it 
either way.

Garret

Received on Wednesday, 27 June 2007 16:57:51 UTC