Is it just me, or is it odd to give an organisation an organisation-name property. Either I'd give a person an organisation-name property, or the organisation a name property.

Norm, how about changing v:n to v:name, and v:fn to v:formattedName or, better yet, v:displayName? In any case, the one or two letter initials ought to go.

Another name issue: while almost all of the name properties (given, family, etc.) can denote order coupled with language, the additional-name property cannot. Not sure if there's any easy way around this though.

There are a few useful features of vCard that aren't supported. Eg home and business phone numbers, and prefered numbers:

TEL;TYPE=home,cell:555-1111

TEL;TYPE=work,cell:555-2222

TEL;TYPE=work,pref:555-3333

These attributes also apply to addresses and emails and are used quite frequently in practice.

Many vCard fields allow lists of multiple values using comma (whilst still allowing comma to be used as a comma by backslash escaping it). Eg, someone with two middle names:

N:Stevenson;John;Philip,Paul;;

or an address with two street address lines:

ADR:;;10\, Downing Street,Westminster;London;;;UK

Features such as the "group." notation for grouping properties would be difficult to implement in RDF, and are so rarely used that it doesn't seem worth trying to support them. vCard is fairly complicated, so it will be difficult to come up with something that makes simple cases simple, but can also be extended to cope with more complicated cases. It would still be useful to come up with a "vCard/RDF Basic" vocabularly though, whilst still allow someone to add "vCard/RDF Super" properties if they needed to do anything fancier (such as ones which take rdf:Collections as values.)

How do you intend to implement things like Photo, btw? As base-64 encoded literals?

I've modelled phone numbers as URIs, so type is simply a property of that URI:

<rdf:Description rdf:about="tel:555-1111"
                 xmlns:v="http://nwalsh.com/rdf/vCard#">
  <v:type>home</v:type>
  <v:type>cell</v:type>
</rdf:Description>

Similarly, middle name is a property and that property can occur more than once with different values. For better or worse, this doesn't preserve order within the group. I modelled photo as an object so you can either point to it with a URI or use a data: URI to encode it "in place".

I’m not sure if any of the existing ontologies follow the approach I want to outline, since I have no appreciable experience with RDF, as of yet (one day I intend to fix that), but I’ve done my share of RDBMS schema modelling, so I do have some opinions.

I believe assigning labels to phone numbers is not the right way to model this. The cleaner approach is to capture that a person has multiple roles; a role is what each piece of contact information is associated with. So rather than modelling a phone number as label + number attached to a person, it is just a number attached to a role attached to a person. Likewise, an email address is attached to a role.

That way you can capture any amount of detail in a very finegrained fashion that simply applying labels to types of contact info cannot match. All sorts of cool things are possible, like easily marking the entire “Acme Corp” role of “John Doe” as “past” when he leaves the company (and discard it as one or keep it for historical reference; how about attaching from/until data to roles?).

You could also allow roles to aggregate other roles, say, when “John Doe” works at two different “Acme Corp” offices; when you don’t know which one he is at today, you want to know all phone numbers he might be reached at.

Going on, you can then model organisations as a special case of a role which has no owner and may aggregate roles belonging to any person.

(If you try to model a person as a special case of a role things get hairy. I tried to sketch this out a number of ways and decided I was running out of oxygen.)

Given a completely free hand, I think I would take an approach along the lines you suggest, Aristotle. However, that's not a model that any PIM I've used actually takes. Nor is it consistent with my understanding of the vCard model. I'm not inclined to use a model that won't map conveniently onto my actual address book.

Sorry, I forgot about the tel: URLs. There could potentially be problems doing that though; PREF is really a property of the relationship rather than the number itself. I share a desk phone at work, I might choose to mark that phone as preferred, but if I did then anyone else using that phone would get it marked as preferred too.

Aristotle: the "group." notation in vCard lets you do some of the things that you mention, but I've never seen it used in practice. An example would be:

x.TEL;TYPE=WORK:555-2222
x.EMAIL:old@example.com
x.NOTE:Old workplace
y.TEL;TYPE=WORK:555-1111
y.EMAIL:new@example.com
y.NOTE:New workplace

Theoretically applications should be able to consume property groups, even if they ignore the grouping.

hm, I don't see the disctinction between adress objects that serve as postal or work or mail or other address.

x - hasPostalAddress - y.

y a Address.

x - hasWorkAddress - z

z a Address.

?

Norm, you say "I've modelled phone numbers as URIs, so type is simply a property of that URI". I feel that is broken: the home/work/vacation is a relationship between me and a contact point which can have adresss and phone number. The same location may be Jack and Jill's home and Jack's workplace, but not Jill's workplace. The contact ontology, which was my take on this many years ago, uses a class of Location for this.

Can't you concluse from the fact that your PIM says someone has a work phone number that they have a workplace which has a phone number? Aristotle, you call these roles, and I think thats the right structure, though I don't think 'role' is the rigth word.

The Mac Addressbook allows you to create your one values for home/work/mobile/etc whcih suggests an advantage in modelling that relationship explicity and dseparately from the phone number.

This really depends on whether the goal is to make a nice ontology or to make the closest one to vcard. I'd be happy with two ontologies with well-known conversions between them.

Oh, and by the way, would you like a w3.org namespace for that in case it catches on and develops (with he greatest of restect for the existing one!).

Hi Tim. I've already changed the way I model phone numbers (probably based on a comment you made in some other forum :-). I now do it this way:

c:phone a owl:ObjectProperty;
    rdfs:label "Phone" .

c:homePhone a owl:ObjectProperty;
    rdfs:subPropertyOf c:phone;
    rdfs:label "Home" .

c:workPhone a owl:ObjectProperty;
    rdfs:subPropertyOf c:phone;
    rdfs:label "Work" .
...

Then I can say: who:tbl c:workPhone "555-1212"; c:homePhone "555-1212" . etc.

Better?

With respect to the W3C namespace, I'm game, I suppose. Though I guess we should have some public discussion somewhere to see if there's actually consensus about the model. As you point out, there's a tradeoff to be made between "a nice ontology" and "modelling vCard". Given that there were several other attempts out there to do ontologies for this sort of thing, I decided to make mine different by attempting to model vCard as closely as possible. But I'm prepared to be persuaded that it would be more valuable if it diverged here and there. (e.g. Bruce's comment about the ugly, short names.)