Re: [vcard] multiple names, multiple address lines

Wait, stop the presses:

Garret Wilson wrote:
> Take a simple telephone number (David already discussed this 
> somewhat). We want to have several of them, and mark one as 
> "preferred". Do we require vcard:tel also to accept a list and only a 
> list? We basically have the following options:

I forgot option #4: <vcard:tel 
rdf:parseType="Collection"><rdf:Description 
rdf:about="+15551212"/></vcard:tel>. Now we have some elegance back into 
the model. And we don't have the "global preference" problem, because we 
simply say that the first telephone number in the list is the preferred one.

My only remaining problem here is that we're forcing a model that is 
only needed for the exception case, not the common case. So I'm back to 
where I started with my first post: is it really so complicated to have 
the following prose in the specification?

"The value of vcard:tel can be either a single resource with a tel: URI, 
or an rdf:List of such resources."

Is this "value-flipping" really going to make life so hard for a 
processor? Here's the same prose for other properties:

"The value of vcard:email can be either a single resource with a mailto: 
URI, or an rdf:List of such resources."

I'd truly be happy with that; it would be elegant in the common case; 
and it would support all the use cases. It only gets slightly more 
complicated with literal values, but that's RDF's fault because of how 
literals are modeled:

"The value of vcard:familyName can be either a literal, a bnode with a 
literal in an rdf:value, or a list of such bnodes."

I could even accept that the idea of "address lines" in vcard:Adr is a 
different type of animal and can only take an rdf:List, if that makes 
people happier:

"The value of vcard:street can only be an rdf:List of bnodes with 
literals in rdf:value properties."

So I guess I'm back to my original position, but after all the options 
we've discussed, it's the one that seems most elegant and flexible, 
without adding a lot of complexity.

Garret

Received on Tuesday, 3 April 2007 15:28:14 UTC