Notes on vCard, LDIF and mappings to RDF



This note discusses a common ontology for the interoperable interchange of contact information, in the light of various pieces of software, the standards which they purport to import nand export, and their interpretations of that software.


Here is an example of contact infromation in vCard.

FN:John Doe
ORG:Example.com Inc.;
TITLE:Imaginary test person
TEL;type=WORK;type=pref:+1 617 555 1212
TEL;type=CELL:+1 781 555 1212
TEL;type=HOME:+1 202 555 1212
TEL;type=WORK:+1 (617) 555-1234
item1.ADR;type=WORK:;;2 Example Avenue;Anytown;NY;01111;USA
item2.ADR;type=HOME;type=pref:;;3 Acacia Avenue;Newtown;MA;02222;USA
NOTE:John Doe has a long and varied history\, being documented on more police files that anyone else. Reports of his death are alas numerous.
item5.X-ABRELATEDNAMES;type=pref:Jane Doe
CATEGORIES:Work,Test group

vCard and icalendar

These share a basic line syntax style. vCard came first, RFC2426 issued concurrently with the generic syntax RFC2425. Later came iCaledar, RFC2445, building on but not using all the types of vcard and using some new ones. Therefore an iCal parser will not necessarily parse a vCard.

Only in vCard

Only in iCalendr


Issues with vCard


The following escaping is done.

(It wasn't clear to me whether theese are at the same level or not. This affects whether you have to encode a backslash as \\ (if there is one level) or as 2^n backslahes if there are n levels of escaping applied to the same data. I conclude that it is a single level)

Another question is whether all the escapes are used when a given syntax doesn't happen to include any comma delimiting. Yes, they are: colons, semicolons, and commas are escaped in all values.


Rfc2426 in the BNF says:

   n-value      = 0*4(text-value *("," text-value) ";")
                  text-value *("," text-value)
        ; Family; Given; Middle; Prefix; Suffix.
        ; Example: Public;John;Quincy,Adams;Reverend Dr. III

The example in the comment is presumably wrong and should IIUC be


There was a discussion on #swig on 2007-01-26 about how to represent this in RDF. One compromise is to use spaces to separate the comma-separated valeus, to cut down on the structure.

Of course, the whole thing could be represented at lists:

  (("Quincy" "Adams") () ("John") ("Reverend" "Dr.")("III"))

but that isn't so much in the RDF spirit and would take a lot of space in RDF/XML. A version with spaces for the multiple values

  [ v:familyName "Quincy Adams"; givenName "John"; v:middleName "";
    v:honorificPrefix "Reverend Dr.", v:suffix "III"]

seems to be a compromise. Giving an empty middle name (or anything else) would be optional.

Modeling issue: Whether to make the name itself a concept

The n filed in vCard seems to echo the dn (distinguished name) field in vcard. The idea f a distinguished name is that it allows one to distinguish (indirectly identify) the person involved. In x.500 systems, DN's often have organizational names and organization units. In Mozilla Thunderbird, the dn is the common name and email adddress pair, which is what is sent in email. In most cases the email address is personal: FOAF uses it as a distinguisher by itself -- it is a nverse functional property. So while people may share an email address, it is going to be a pathological case in which who people share the common name and email adderss pair. (One could imagine a shared family email where the father and son have the same common name.)

Should the name itself be a concept, or should the subfields of the name be attributed to the person? In the first case in RDF it becomes a bnode. This is quite easy, but makes the data more complicated.

The actual parts of the DN are in FOAF and Thunderbird all separate fields anyway. You can't have two different family names, titles, suffxies, etc. Suppose we remove the bnode and the abstrction of the 'name' as a complex object itself.

Do people validly have multiple alternative names? Yes, they can have in the case of nom de plume, names befroe and after acquiring a peerage, and so on. However, none of the contct list software I have come across alows one person to have two names. One could in AB (and in RDF) use a relation field to specify that one name (Persona) is in fact the same person as another. vCards would then represent information about personas. These personas have names, if we are to be strictly accurate. This would make the subject of all these arcs a persona rather than a person. If we are not, then we would get a situation where to personas are identified as being the same person, and

  1. Restrict a person to only having one name in the model
  2. Allow two names for any person
  3. Change the domain of the name (and vcard in general) to persona, restrict the persona to having one name, and allow a person to have more than persona.
In this case I feel that these are in the order from pragmatic to

Modeling issue: Whether to make the contact point a concept

The contact ontology, of all the ontologies cosidered, is the only one which allows you to have two workplaces, with an address and phone number for each, and hang onto whih goes with which. That is because it has a abstraction con:ConcatLocation, or perhaps better contactPoint or even Role, which is the thing which is labelled 'home' or 'work' typically, or sometimes 'vacation' or 'emergency'. Of these, home and work outnuber the others by far. Some systems allow you just one set of home and one set of work details (thunderbird). AB allows you to have work, home, other and even to set you own relationships and also to have more than one of each. The UI would not be that complicated to attach URLs etc to work or home groupings.

vCard allows groups, and the spec shows them being used in exactly this way. However, AB does not use groups in this way.

circles and arrows

Relations between different properties used to model adresses in the con: (brown), prooposed vCard RDF (dk. blue), ldif (green) and mozilla-extended LDIF (cyan).

In this case, my conclusion is that the generality of modelling the contact-point as a node in the graph is important.

(It is interesting to ask whether a contact-point has some of the attributes of a role, or of a persona mentioned above. It seems to. One can imagining being addresses at a different address, for example, in a role. (The Hon. Basil Graham, Chair, Happytown Town Council, vs. Bas Graham, 23 Accacia Avenue, Happytown). This not, however, what the software we are dealing with supports.

As multiple workplaces and homes are not uncommon, The author's conclusion is for a common ontology it is valuable to model the contact-point.

The argument against modeling the contact point is the complexity of the user interface for editing. The user interface for output is straightforward.

There is considerable tension throughout the ontologies reviewed between associating things with people, or their work.

Work email?


In Apple's address book a type can be WORK, but in the spec, but WORK is not in email-type. I extended the VCARD spec in the implementation vcard2n3.py to cover this.

FOAF just uses a personal mailbox, with the constraint that (no two people can share it), with no attribution of work or home. If v:work-email and foaf:mailbox are both subproperties of general email property, but not of each other, then there ill be limited interoperability.

Many commercial systems seem to make rash assumptions when importing data, deciding, sometimes under user guideance and sometimess without asking, whether to decide tha an unknown address is a work or home one. This addition of random false data can make a database very dirty. To avoid this, the ontology used for interoperability must have sufficient delicacy to represent just what is known, no more and no less. users should be in the loop when it is necessary to classify names and addresses for input into a particular system.

Group semantics

There seem to be two different assumptions about the grouping system. In the spec, an example gives the group name some semantics.

home.tel;type=fax,voice,msg:+49 3581 123456
home.label:Hufenshlagel 1234\n

but in Apple AB it doesn't, the semantics comes from a type= on the address, and phone numbers cannot be attributed to specific addresses. (That is an AB bug IMHO).

item1.ADR;type=HOME;type=pref:;;3 Acacia Avenue;Newtown;MA;02222;USA
item2.ADR;type=WORK:;;2 Example Avenue;Anytown;NY;01111;USA

Age-old modeling issue: First/Given/Last/Surname

It is a fact that some cultures (such as Japan) normally put names in the order (family, given), and some (like the US) in the order (given, family). (There are also cultures who don't use either of these simple schemes, but that is another question.) It is therefore unreasonable and politically incorrect to assume that a first name is a family anme or a given name in general, except within a local community.

In the ontologies and software reviewed, MacAB and Thunderbird both use "first" and "last" in the user interface.

Apple AddressBook extensions

Some extensions noticed in real data from an Apple AddressBook (AB)


Guessing, as the country name is covered, this field is the foratting and editing convention, for example where the potscode comes in the address and whether it called a postcode, zipcode etc.. In AddressBook program, this is a global preference. I don't know whther you can create some cards with a US fromat and some with a french format. It would be useful if the format was a function of the country.

item1.ADR;type=HOME;type=pref:;;3 Acacia Avenue;Newtown;MA;02222;USA


This is a nice feature. It makes the item sort and sisplay as primarily the organization, secondarily the person.

FN:AMC Theatres Burlington Cinema 10
ORG:AMC Theatres Burlington Cinema 10;
item1.ADR;type=WORK;type=pref:;;20 South Avenue;Burlington;MA;01803;




The ABLabel gives the relation, either apple standard in ehich case surrounded by weird characters, or else user-generated. Apple values in apple-special namespace. User-generated field in user-namespace, maybe a parameter to be passed to the translator. These are used to override the predicate linking the person and the group. It may be that when the group is a 2-item thing, just something and label it should be de-reified to a single prediate-object statement. This is necessary to be able to use homepage for example as an inverse functional property to identify people

item1.X-ABRELATEDNAMES;type=pref:Jane Doe

This would be represented in N3, sing a special namespace for AB relative names,

   abl:spouse "Jane Doe";

Meanwhile, a different namepscae should be used (per user?) for user-generated names. these are more like tags, very user-specific.

item1.X-ABRELATEDNAMES;type=pref:Jane Doe

This would be represented in N3 more like: names,

   user:coathor "Jane Doe";

Issues with the Representing vCard Objects in RDF/XML

Use of Seq

I prefer lists (RDF collections) instead.

Property name conventions

Good pratice is initial lower case on property names, as in vcard:family not vcard:Family. Use upper case for classes, as in foaf:Person.

postOfficeBox not post-office-box, or prerably shorter poBox as these are only codes whose mnemonic value is for developres, not users. organization-name is too long: orgName, orgUnit would be fine IMHO.

Direct mapping

v:work-email can be generated from EMAIL:TYPE=WORK: automatically, in a way which can be extended for new orms of endpoint (AIM, Skype, etc) and new forms of location (vacation, emergency, etc). Having longer names makes this impossible, or more complicated.


The existence of the v:unlabeledTel Property as an (explicitly) unlabeled phone number of a person suggests that an unlabelled phone number has extra semantics in its being un labelled. I think it is safest to model that a lack of label means a lack of informtion, and that a label could be inferred or added elsewhere.

LDIF: LDAP Data Interchange format

LDIF is is the format which Mozilla (e.g. Thunderbird) takes for import/export of an address book. LDIF in Wikipedia

Here is a fairly full ldif file exported from Thunderbird version (20061207):

dn: cn=Zackery Zephyr,mail=zac@example.com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: mozillaAbPersonAlpha
givenName: Zackery
sn: Zephyr
cn: Zackery Zephyr
mozillaNickname: testnick
mail: zac@example.com
mozillaSecondEmail: zackery@example.org 
nsAIMid: zaco
mozillaUseHtmlMail: false
modifytimestamp: 0Z
telephoneNumber: +1 202 250 2525
homePhone: +1 202 250 2526
fax: +1 202 250 2527
pager: +1 202 555 2525
mobile: +1 202 555 2526
homeStreet: 1 Zephyr Drive
mozillaHomeStreet2: Apt 26
mozillaHomeLocalityName: Zoaloc
mozillaHomeState: MA
mozillaHomePostalCode: 02999
mozillaHomeCountryName: USA
street: 1 Enterprise Way
mozillaWorkStreet2: Suite 260
l: Zoaloc Heights
st: MA
postalCode: 02998
c: USA
title: Chief Test dataset
department: Testing
company: Zacme Widgets
mozillaWorkUrl: http://example.com/test/zac
mozillaHomeUrl: http://zac.example.net/zac
mozillaCustom1: custom1 value
mozillaCustom2: custom2 value
mozillaCustom3: custom3 value
mozillaCustom4: custom4 value
description: This is a n imaginary person.


In LDIF, the following backslah-escaped

ans also a \XX form of hex-escaping.

Issues with LDIF

The names obviously have a varied and long history, resuting in certain inconsisetncy which need not bother us.

Apart from the 'dn' Distinguished Name field, the structure is completely flat. The vCard MIME profile was, I gather, orginally designed to be compatible with the x.509 directry structures. However, the fields used in a thunderbird dn don't map to the fields in a vCard N fields.


See the following for more background.


RFC2425: A MIME Content-Type for Directory Information Defines text/directory . the line-folding and basic record type structure.

RFC2426: vCard MIME Directory Profile defines most of the vocabulary specific.

An RDF vcard namespace currently (2007) being developed in Namespace http://www.w3.org/2006/vcard/ns

Harry Halpin, Brian Suda, Norman Walsh An Ontology for vCards is an ontology which is the latest mapping, to which this is a set of comments.

History: The obsolete Representing vCard Objects in RDF/XML is a W3C Note on this from Renato Iannella of IPR Systems in 2001. Harry took an action to contact Renato in the 2006-11-03 #swig meeting. A chat on #SWIG was held on 2007-01-26, at which Harry presented a conversion table betwen thse fromats


LDIF in Wikipedia is a good place to start.

RFC2840, The LDAP Data Interchange Format (LDIF) - Technical Specification This is the spec.

RFC2253: Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names defines the format of the distinguishes name string.

Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension only affects updates to LDAP stores, so we don't need to worry about this.

RFC4510: Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map is the master spec pointing to the bits of LDAP. LDIF was defined for LDAP, but does not depend on it.

Python iCalendar (vcard?) implementtions which may work for vCard include

Tim BL, 2007-01