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

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

Yes.


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

No.

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

No. I've considered this in some ontologies I've created (for exactly 
this problem), but it seems a shame to create two properties with 
identical semantics except that the value will be different. In essence, 
this is v:additionalNameIfYouOnlyHaveOneAdditionalName and 
v:additionalNameIfYouHaveMoreThanOneAdditionalName. We surely wouldn't 
want v:additionNameIfYouHaveExactlyThreeAdditionalNames . :)


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

Yes. This was my original proposal and my favorite, although The 
Compromise (1a above) comes in a close second.

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

No. I agree that some of the same problems crop up, but because 
honorable prefixes and honorable suffixes are almost a known universe, a 
processor can easily present the correct order when needed. (In fact, 
the order may vary among locales---I don't know.) I think that, compared 
to names, prefixes and suffixes are sufficiently detached from the name, 
small in number, and reasonably understood semantically not to warrant 
lists.

Garret

Received on Thursday, 26 July 2007 22:40:41 UTC