Re: vCard/iCalendar RDF process document 2007-04-06

Good questions Garret :-)

I'll answer where I can ...

On May 1, 2007, at 12:59 PM, Garret Wilson wrote:

>> ought to be literal properties restricted to a maximum cardinality of 
>> 1.
>
> To understand the implications of your and Norm's position, let me ask 
> a few followup questions:
>
> 1. Do you believe that multiple honorific suffixes should be placed 
> into one literal value, such as 
> <vcard:honorificSuffix>BS,JD,MBA,JR"</vcard:honorificSuffix>?

I guess no.

I'm not sure I'd call the first three proper honorific suffixes (more 
like "holds degree"). I'd say if someone really insisted on calling 
them that, it wouldn't hurt to have them as separate properties.

> 2. Which of the following representations do you prefer: 
> <vcard:familyName>bin Muhammad bin 'Awad bin Laden</vcard:familyName> 
> or <vcard:familyName>bin Muhammad,bin 'Awad,bin 
> Laden</vcard:familyName> (i.e. the family name components separated by 
> some delimiter)?

I'm fairly ignorant of Arabic, but would tend to say the first. I'd 
defer for sorting logic to the sort string property.

> 3. Do you believe that vcard:adr should also have a maximum 
> cardinality of 1, considering the need to support multiple addresses 
> with a "preferred address" designation?

No.

I'd say if there's a need to denote a preferred address, perhaps there 
ought to be a preferredAdr property? It is a relation, after all. In 
fact, what address I prefer you use is all about context anyway (if 
we're doing business, use my business address, and if personal, send to 
my home).

I think personal name parts are somewhat unique, because they have 
(often simply assumed) expectations about using them for sorting and 
display. It's this significance of order that is such a pain in 
general.

Mind you, I'm not dismissing the real world difficulties here. I want 
to use this stuff for bibliographic data for citation purposes, where 
display and sorting is very important. But I'd much prefer a simpler 
approach if at all possible.

> 4. Do you believe that vcard:tel should also have a maximum 
> cardinality of 1, considering the need to support multiple telephone 
> numbers with a "preferred telephone number" designation?

As above.

> 5. Do you believe that vcard:email should also have a maximum 
> cardinality of 1, considering the need to support multiple email 
> addresses with a "preferred email address" designation?

As above.

> 6. Would you support abandoning the class vcard:N in favor of simply 
> using the property vcard:n in the form 
> <vcard:n>Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.</vcard:n>? If 
> no, then why not? (i.e. I'm curious to know whether your answers to #1 
> and #6 are different, as the questions are very similar.)

Let me step back a bit:

In the vCard spec, what do the commas and semi-colons mean? For 
example, how is the fragment "Philip,Paul" understood? Does the spec 
say this is a comma-delimited list of given (or "other"?) names? Is a 
notion of ordered list included in the spec?

Bruce

Received on Tuesday, 1 May 2007 17:23:12 UTC