Four Questions to Resolve VCard Issue on Ordering/Unordering

Garret Wilson wrote:


[snip]
> Let v:givenName take a literal or a list, as the need allows, but
> there was a lot of opposition to this "value-switching". The same with
> v:familyName and v:additionalName.
Please answer the questions, everyone, including Garrett. I am
continually reframing them to help this debate along, as I want the
vCard spec to approximate doing  The Right Thing while reflecting the
will of swig. Note that we *only* arguing about additionalNames, not
everything.

So, here's one proposal:

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


    I am fine with that hack if the rest of the editors are and there
are no objections from the swig list. I am also fine with using rdf:Seq.
I find in doubtful the distinction between rdf:Seq and rdf:List will
matter in practice, and the only problem the hack leaves is that we
would have to explain it a bit in the document, since it's non-standard
unlike rdf:Seq.

1b) The Range of AdditionalNames is rdf:Seq

    Note that the compromise does not want that lists for all name
elements, only for additionalNames (although I think it might be useful
for honorable prefixes and suffixes).

    So, if one chooses 1a) this would prefer the hack proposed by
Jeremy/Sandro for dealing with, say, my middle name Reeves and my
baptized name (a sort of Catholic middle-name) Edward.

 <vCard:additionalNames rdf:parseType="Collection">
      <rdf:Description owl:sameAs="Edward"/>
      <rdf:Description owl:sameAs="Reeves"/>
 </vCard:additionalNames>. 



    Yet it seems a bit silly if one person has a single middle-name,
that they would have to write this as a rdf:List or rdf:Seq

<vCard:additionalNames rdf:parseType="Collection">
  <rdf:Description owl:sameAs="Reeves"/>
</vCard:additionalNames>

    as opposed to

<vCard:additionalNames>Reeves</vCard:additionalNames>

    As there is no clear notion of ordering "middle-names" with
"baptized names", other than that both come in between my first name and
last name. It seems strange to force ordering on something that has no
ordering, but then vice-versa is equally true.

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. 

	So, one could say:

 <vCard:additionalNames rdf:parseType="Collection">
      <rdf:Description owl:sameAs="Edward"/>
      <rdf:Description owl:sameAs="Reeves"/>
 </vCard:additionalNames> 

	if one wanted order, but if one wanted no order, one could say:

 <vCard:additionalName>Edward</vcard:additionalName>
 <vCard:additionalName>Reeves</vcard:additionalName>

3) We just take away any range constraint on vCard:additionalNames, so one can do both ordering and unordering with a single property, but with:
 
 <vCard:additionalNames rdf:parseType="Collection">
      <rdf:Description owl:sameAs="Edward"/>
      <rdf:Description owl:sameAs="Reeves"/>
 </vCard:additionalNames> 

	and

 <vCard:additionalNames>Edward</vcard:additionalNames>
 <vCard:additionalNames>Reeves</vcard:additionalNames>


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

	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."

	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. 

	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. 

[1] http://www.w3.org/2002/12/cal/rfc2426#sec3.1.2






> Garret


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Thursday, 26 July 2007 19:21:51 UTC