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

Harry Halpin wrote:

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

I've been hesitating to respond to this because I think it's a big mess 
and I don't know the best way forward. My impulse is the same as it's 
always been, which is to keep things simple and treat name part 
properties as
strings.

But ...

> So, here's one proposal:
> 
> 1a) The Range of AdditionalNames is rdf:List.

I'm not going to say yes or no on this, but will simply say that if we
want to preserve order for additional names, then I'd prefer using List.

But I don't think the convention of treating all but the first given
name as "additional names" will work for a whole lot of real world 
names. Examples:

 J. Edgar Hoover
 José Ortega y Gasset

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

No to Seq.

...

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

I would do:

 vcard:additionalName "Edward Reeves" .

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

No comment.

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

This is where we get to the interesting/difficult part.

If we're going to be consistent, I see no reason why we limit our choice 
to additionalName. The same approach should be used throughout.

But given that Garret feels strongly it is essential to treat names as 
ordered lists, and I and others prefer a simpler modeling that treats 
them as strings, we end up with twice as many name properties if we go 
with the singular/plural approach.

Bruce

Received on Friday, 27 July 2007 01:50:54 UTC