vCard in RDF: Problems and Resolutions

By Garret Wilson

Version 2007-03-27

Lead

A proposal for RDF representation of vCard, with implications for the RDF Calendar project and names in FOAF.

Metadata, Names, and the vCard

Metadata is not a new concept, and the idea of a name of a thing is one universal and very personal example of a metadata property that has existed since language began. The vCard, defined in RFC 2426, vCard MIME Directory Profile, is one standard method of storing and transferring metadata about a person, including that individual's name, address, and contact information. The vCard standard was defined early on in the Internet revolution, long before the release of the first RDF working draft, and it is still common to see vCards attached to emails, downloaded from web site, and used as a transfer mechanism between personal information managers such as Microsoft Outlook.

vCard was formulated before XML existed, and opts for its own simple text-based serialization. An example vCard appears below:

begin:vcard
version:3.0
fn:Dr. Mary Ann May Smith, Jr., M.D.
n:Smith;Mary;Ann,May;Dr.;Jr.,M.D.
n;language=es:Smith;Maria;Ann,May;Dr.;Jr.,M.D.
org:Example Corporation
adr;type=work,postal,parcel:;;123 Some Street;Springfield;NY;12345;USA
tel;type=voice,msg,work:+1-123-555-1212
email;type=internet,pref:jsmith@example.com
email;type=internet:jsmith@example.org
url:http://www.example.com/~jsmith
end:vcard

A single line from above example will help to better understand the general format of a vCard:

type;optionalParameters:single;value;or;structured;value
n;language=es:Smith;Maria;Ann,May;Dr.;Jr.,M.D.

As can be seen, each line of a vCard begins with a type, followed by an optional set of parameter=value pairs. In the example above, the type n indicates that this is a vCard name definition. The optional parameter language indicates by es that this is the Spanish form of the name. After that appears the value; for the n type, the value is a structured value separated by semicolons, with the components indicating family name, given name, additional names, honorific prefixes, and honorific suffixes, respectively.

In today's world, with the popularity of the XML syntax, the semantic rigor of RDF, and interoperable ontologies such as those provided by Dublin Core and FOAF, creating a representation of vCard in RDF+ML would seem ideal and obvious. Indeed, in 2001 there was an effort to create just such a formulation; the result can be seen in a 2001 W3C Note, Representing vCard Objects in RDF/XML.

There are several problems that spring immediately from the existing RDF vCard specification, however:

vCard and Directory

To find a comprehensive, rigorous, yet elegant solution for representing vCard in RDF, it is beneficial to take a step back and find out the context in which vCard was created. vCard was not created in a vacuum. The title of RFC 2426, vCard MIME Directory Profile, gives a hint about its status in life. vCard is formulated as a profile of a more general text/directory MIME storage format defined in RFC 2425, A MIME Content-Type for Directory Information , much in the same way that the FOAF Vocabulary Specification is an ontology of RDF. Most of the syntactical requirements of each vCard content line, and even many semantic entities such the language parameter type, are defined in RFC 2425 (Directory) and only included by reference in RFC 2426 (vCard). Many individual semantic elements specific to RFC 2426 (vCard), such as the meaning of the N name components, are in turn derived from ITU-T X.520 and X-521.

The relationship of vCard to the Directory syntax and framework is especially interesting because of another similar format that some have attempted to convert to RDF+XML: RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar). The iCalendar format has recently become popular by providing interoperability among such applications as Apple's iCal and Mozilla's Sunbird. Although RFC 2445 (iCalendar) explicitly states that it is not technically a profile of RFC 2425 (Directory), it is "based upon the syntax" and "does reuse a number of elements" from that specification.

This close relationship among RFC 2425 (Directory), RFC 2426 (vCard), and RFC 2445 (iCalendar) becomes significant when formulating an RDF version of vCard. Some parts of an RDF vCard vocabulary might be better generalized in light of its relationship to a more general framework, Directory. Furthermore, the experience of efforts to create an RDF version of iCalendar, such as represented by the W3C's RDF Calendar Workspace, may have bearing on attempts to do the same with vCard and vice versa. (One obvious consideration that can be mentioned already is that the W3C RDF Calendar effort uses lowercase names for iCalendar RDF properties.)

The FOAF Name Problem

Related to this discussion is an ontological design issue that has been raised by the Friend of a Friend (FOAF) Project, which has a goal of "creating a Web of machine-readable pages describing people, the links between them and the things they create and do." The aforementioned FOAF Vocabulary Specification defines an RDF ontology that includes such types as foaf:Person and foaf:Organization. Also included are properties relevant to humans, such as foaf:name, foaf:mbox, foaf:homepage, and even foaf:myersBriggs and foaf:dnaChecksum (the latter of which is admitted to be "mostly a joke" to reiterate the purpose of FOAF in describing people).

FOAF obviously covers some of the same metadata ground as does vCard, especially with its foaf:name property. Also included are other name-related properties such as foaf:firstName, foaf:givenname, foaf:firstName, foaf:family_name, and foaf:surname. It has been noted that the syntax and semantics of these names seem haphazard, incomplete, and conflicting all at the same time. This FOAF name vocabulary issue has been under discussion since at least as far back as 2000, with no resolution yet reported and no progress apparent for the past few years as of 2007. One proposal, Names in Foaf, tries to combine the "adopt existing guidelines" and "roll your own" approaches by creating a single foaf:sortName property, the value of which is an ordered list of RDF classes, each representing a component of the name, such as in this example:


<foaf:Person>
  <foaf:sortName xml:lang="es" rdf:parseType="Resource">
    <rdf:li><foaf:FamilyName rdf:value="Smith"/></rdf:li>
    <rdf:li><foaf:GivenName rdf:value="Maria"/></rdf:li>
    <rdf:li><foaf:GivenName rdf:value="Ann"/></rdf:li>
    <rdf:li><foaf:GivenName rdf:value="May"/></rdf:li>
    <rdf:li><foaf:HonorificTitle rdf:value="Jr."/></rdf:li>
    <rdf:li><foaf:HonorificTitle rdf:value="M.D."/></rdf:li>
  </foaf:sortName>
</foaf:Person>
</rdf:RDF>

While this proposal makes no explicit reference to RFC 2426 (vCard) and its predecessor specifications, the similarity is striking. There are some detractions from this proposal, though:

As a reaction to the complexity of this approach, another suggestion, Names in Foaf - An alternate proposal has been to do away with all properties except foaf:name. In their place would appear a small set of properties—foaf:familiarName, foaf:informalName, foaf:formalName, and foaf:fullName—reflecting the use of names in different situations. These new properties would abandon any semantic identification of name parts, making it difficult to machine-process identification subcomponents as well as transfer data round-trip from existing standards.

A useful solution to representing human names in RDF should be as simple as possible. However, it should not be so simple as to lose semantics when transferring data from existing formats. Basing a solution on an existing standard would be ideal, but the transformation to RDF should be based upon a set of rules that would provide consistency as well as completeness, allowing straightforward data round-tripping between representations. One solution that meets these criteria is presented here.

Directory, vCard, and iCalendar in RDF

Analogous to Python script logic that is described in the W3C RDF Calendar document, is is possible to create a set of conceptual rules that can be used to transform the Directory, vCard, and iCalendar formats to RDF ontologies. We can start with the RDF ontology namespaces and recommended XML prefixes, which will each represent one of the profiles or pseudo-profiles of Directory, and will give an indication of how the work is to be divided up:

directory
http://globalmentor.com/namespaces/directory#
vcard
http://globalmentor.com/namespaces/directory/card#
icalendar
http://globalmentor.com/namespaces/directory/calendar#

A set of guiding rules might then start as follows:

This produces the following RDF version of the name part of the vCard example introduced earlier, assuming that the properties are used to describe a foaf:Person:

<foaf:Person>
  <card:fn>Dr. Mary Ann May Smith, Jr., M.D.</card:fn>
  <card:n>
    <card:N>
      <card:familyName>Smith</card:familyName>
      <card:givenName>Mary</card:givenName>
      <card:additionalName rdf:parseType="Collection">
        <rdf:Description rdf:value="Ann"/>
        <rdf:Description rdf:value="May"/>
      </card:additionalName>
      <card:honoraryPrefix>Dr.</card:honoraryPrefix>
      <card:honorarySuffix rdf:parseType="Collection">
        <rdf:Description rdf:value="Jr."/>
        <rdf:Description rdf:value="M.D."/>
      </card:honorarySuffix>
    </card:N>
   </card:n>
  <card:n>
    <card:N>
      <card:language>es</card:language>
      <card:familyName>Smith</card:familyName>
      <card:givenName>Maria</card:givenName>
      <card:additionalName rdf:parseType="Collection">
        <rdf:Description rdf:value="Ann"/>
        <rdf:Description rdf:value="May"/>
      </card:additionalName>
      <card:honoraryPrefix>Dr.</card:honoraryPrefix>
      <card:honorarySuffix rdf:parseType="Collection">
        <rdf:Description rdf:value="Jr."/>
        <rdf:Description rdf:value="M.D."/>
      </card:honorarySuffix>
    </card:N>
   </card:n>
</foaf:Person>

About the Author

Garret Wilson provides consulting on Internet standards through his company, GlobalMentor, Inc..

Copyright © 2007 GlobalMentor, Inc.