W3C home > Mailing lists > Public > semantic-web@w3.org > June 2007

Re: vCard RDF compromises

From: Tim Berners-Lee <timbl@w3.org>
Date: Tue, 26 Jun 2007 20:08:13 -0400
Message-Id: <F2E81E5C-A6CE-4483-B593-F7CA624486C7@w3.org>
Cc: semantic-web@w3.org
To: Garret Wilson <garret@globalmentor.com>


1. Do you have a pointer  to the latest spec?

2. The discussion is, then, in the archives to this list with 'vcard'  
in the subject?

Tim

On 2007-06 -26, at 17:38, Garret Wilson wrote:

>
> Everyone,
>
> I've been busy with other areas of my current project, but this  
> week I'm officially back to the vCard RDF part. I will be  
> implementing the new vCard stuff literally within days, so I'd like  
> to get resolution on some of the issues. I'd really like to share  
> W3C work, so I'm prepared to make compromises (see archives for  
> earlier discussions on these issues):
>
> VCard:N
>
> There are a few people absolutely loathe to have any processor- 
> based value-switching, and I'm loathe to cram all the name  
> information into one value. In the interest of getting this done, I  
> offer the following compromise: N.familyName, N.givenName,  
> N.honorificPrefix, and N.honorificSuffix are all single value  
> properties, although you can have multiple of them.


You mean   one would say (with vcard as the default namespace)

#mjws  N   [ givenName "Mary Jane";  familyName "Wocester Smith";  
honorificSuffix "M.D. PhD"]

or really

#mjws   N.givenName "Mary Jane";  N.familyName "Wocester Smith";  
N.honorificSuffix "M.D. PhD".

sorry i've fallen behind on this

> N.additionalNames takes a value of rdf:List.
>
> VCard:Adr
>
> Adr.streetAddress takes a single value, but Adr.extendedAddress  
> takes a value of rdf:List.

sounds reasonable to me.

>
> Let me know as soon as possible what people thing about these  
> suggestions. Since I'm partially caving here, I'd really like to  
> switch to camelCase and get an updated version of the spec soon.  
> Comments?
>
> Best,
>
> Garret
Received on Wednesday, 27 June 2007 00:08:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:57 UTC