Re: Four Questions to Resolve VCard Issue on Ordering/Unordering

On 2007-07 -26, at 15:21, Harry Halpin wrote:

> 1a) The Range of AdditionalNames is rdf:List.

	I prefer this.  I think we should fix the rdf/xml problem in parallel.
	Much the most compact in N3. Has the right semantics.

> 1b) The Range of AdditionalNames is rdf:Seq

	I guess could live with, but I really don't like it.
	Tempted to write the Tabulator so it  converts Seqs into collections  
on load.
	Shame to use Seq for new design.


>
> 2) One could have in addition to an ordered additionalNames, one  
> could have an unordered vCard:additionalName that allowed both  
> ordered and unordered without value-switching.

	That I could live with too, if the unordered from were only used  
when there wa just one.
	 I would probably write rules to convert from the singular to the  
plural.
	The plural would be the canonical form.
  	The idea of non-ordered multiple names is new to me, and new to  
vCard I think.
	So if you have it, that is interesting, but I'm inclined to make you  
make a choice asto whcih order you
	want to present yourself in.

> 3) We just take away any range constraint on vCard:additionalNames,  
> so one can do both ordering and unordering with a single property,
	
	No no no. Horrible.

> 4) Should we extend the compromise (between 1,2, and 3) to  
> vcard:honorable-prefix and vcard:honorable-suffix.

	1 Maybe.  That would map vcard.

>
> 	I think the key part of the vCard Spec[1] is that for ordering, if  
> we take it seriously, we should be able to order the entire name,  
> as the spec suggests:
>
> "     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
>        by the SEMI-COLON character (ASCII decimal 59). Individual text
>        components can include multiple text values (e.g., multiple
>        Additional Names) separated by the COMMA character (ASCII  
> decimal
>        44). This type is based on the semantics of the X.520  
> individual name
>        attributes. The property MUST be present in the vCard object.
>
>
> Type example
>             N:Public;John;Quinlan;Mr.;Esq.
>             N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."

	I know that  KBE and FRS are to be in a particular order, not to  
mention "Prof. Sir" not "Sir Prof.".
	But  I'd be happy for them to be modeled as  strings to, not lists.
	Herr Prof. etc in German too is very ordered.

	I'd be inclined to make N the big set of lists which maps N  
directly, and leave foaf:name like thing as what one actually uses in  
many cases as a label for someone, where one is not trying to address  
an envelope formally or distinguish them as carfeully as possible.

>
> 	It seems there is an ordering of suffixes and prefixes in this  
> example in the Spec, and a restriction of cardinality=1 for family  
> name and given-name.

In which spec?  There can be many ordered family names in Spain.


>
> 	So, please answer the question is detail (as in, 1) "yes" 2) "no"  
> 3) "no" 4) "yes") with any supporting comments or examples, and as  
> soon as I get something resembling consensus (by end of the day  
> hopefully, since this is such an active topic), I will hit  
> republish button on the spec.

KUTGW!
Tim

Received on Thursday, 26 July 2007 22:15:13 UTC