$Id:
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.
BEGIN:VCARD VERSION:3.0 N:Doe;John;;; FN:John Doe ORG:Example.com Inc.; TITLE:Imaginary test person EMAIL;type=INTERNET;type=WORK;type=pref:johnDoe@example.org 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 item1.X-ABADR:us item2.ADR;type=HOME;type=pref:;;3 Acacia Avenue;Newtown;MA;02222;USA item2.X-ABADR:us 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. item3.URL;type=pref:http\://www.example/com/doe item3.X-ABLabel:_$!<HomePage>!$_ item4.URL:http\://www.example.com/Joe/foaf.df item4.X-ABLabel:FOAF item5.X-ABRELATEDNAMES;type=pref:Jane Doe item5.X-ABLabel:_$!<Friend>!$_ CATEGORIES:Work,Test group X-ABUID:5AD380FD-B2DE-4261-BA99-DE1D1DB52FBE\:ABPerson END:VCARD
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.
etc
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
Quincy,Adams;;John;Reverend,Dr.;III
or
Adams;John;Quincy;Reverend,Dr.;III
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.
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
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.
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.
EMAIL;type=INTERNET;type=WORK;type=pref:Libby.Miller@bristol.ac.uk
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.
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 item1.X-ABADR:us item2.ADR;type=WORK:;;2 Example Avenue;Anytown;NY;01111;USA item2.X-ABADR:us
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.
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 item1.X-ABADR:us
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; item1.X-ABADR:us X-ABShowAs:COMPANY
item3.URL;type=pref:http\://www.robots.ox.ac.uk/~acme/joe.htm item3.X-ABLabel:_$!<HomePage>!$_
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 item1.X-ABLabel:_$!<Spouse>!$_
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 item1.X-ABLabel:coauthor
This would be represented in N3 more like: names,
user:coathor "Jane Doe";
I prefer lists (RDF collections) instead.
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.
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.
Here is a fairly full ldif file exported from Thunderbird version 1.5.0.9 (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.
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