hcard-singular-properties

hCard singular properties

This is an explanation of the list of singular properties in hCard.

The analysis here is derived from a thorough reading and analysis of the specific property definitions in the vCard RFC 2426 spec, along with reasoning using physics, and legal name precedents.

This summary is provided because that thorough reading and analysis takes a long time, and while repeatable, is not something that is worth encumbering other developers with. See the Reasoning section for more.

Editor/Author

Tantek Çelik

Contributors

Tantek Çelik, Ryan King

Name Properties

n

The vCard represents a single directory object. Legal precedents afford a person a single given-name (with multiple additional-name(s)) and single family-name, thus, only a single "n" property is permitted.

Possible exceptions that may deserve further research:

• UK.
  • A Change of Name Deed will not change the name on the person's certificate of birth. For instance, when applying for a passport, both the Birth Certificate and the Change of Name Deed would need to be presented as documents of identity. [1]. However even in this case, the passport received from that application process will still have *a* given-name as perhaps the first of many, and thus it is that first passport given-name that may be taken as *the* given-name in hCard, and the remaining given-name(s) if any are simply additional-name(s) in the vCard/hCard vernacular.
  • [When a formal change of name is recorded by use of (an optional) Deed poll] the name change only operates for the future. Previous time-dependent legal documents, certificates etc. retain the prior name [2].
  • There is "a Common Law right, established over the centuries, to be known by any name or any multiple names that we wish, provided that we are not using these name to defraud or mislead." [3]
  • The wife of the [former] Prime Minister, Mrs. Cherie Blair appears in court under her professional name of Ms. Cherie Booth QC (ibid)

fn

A person has only one "best" / most preferred way of formatting their name, and legally organizations have only a single name, thus "fn" is singular.

sort-string

When sorting a name, it doesn't make sense for it to have more than one way of sorting it, thus "sort-string" must be singular.

Physical Properties

bday

A person only has a single physical birthday (reincarnation cannot be scientifically substantiated and thus constitues the creation of a new directory object rather than the re-birth of an existing object, and being "born again" is not the physical event that "bday" represents). Thus "bday" is singular.

geo

The "geo" property represents the person's actual location, not a coordinate approximation of an "adr". A person cannot be in more than one location at a time. Thus a person can only have a single "geo" property.

tz

The "tz" property is the same. A person can only be in a single time zone at a time.

Entire vCard Properties

class

The "class" property indicates the confidentiality/access classification of the hCard as a whole, and thus it only makes sense for there to be one (or rather, makes no sense for there to be more than one).

rev

From RFC2426:

To specify revision information about the current vCard.

The "rev" property represents the datetime of the revision of the hCard as a whole, thus it doesn't make sense for there to be more than one.

uid

The "uid" property is a globally unique identifier corresponding to the individual or resource associated with the hCard. It doesn't make sense for an hCard to have more than one "uid".

reasoning

Reasoning and methodology.

Ryan King and Tantek Çelik basically analyzed both the language of the vCard specification, and did logical analysis on the semantics of each property to determine its singular vs. plural status. We wanted to minimize the introduction of new rules/assumptions as much as possible (per the principles). Relying upon only the vCard specification and logical reasoning seemed the best way to do so.

related pages

• hCalendar singular properties
• hCard
• hCard cheatsheet - hCard properties
• hCard creator (feedback) - create your own hCard.
• hCard authoring - learn how to add hCard markup to your existing contact info.
• hCard examples - example usage of various classes within hCard.
• hCard examples in the wild - an on-going list of websites which use hCards.
• hcard-supporting-user-profiles - sites with user profiles marked up with hCard - a very common example.
• hCard FAQ - if you have any questions about hCard, check here.
• hCard implementations - websites or tools which either generate or parse hCards.
• hCard parsing - normative details of how to parse hCards.
• hCards and pages - semantic distinctions between different hCards on a page, and how to identify each
• hcard-user-interface - techniques and issues surrounding user-interfaces to author, publish, and display hCards.
• hCard profile - the XMDP profile for hCard
• hCard singular properties - an explanation of the list of singular properties in hCard.
• hCard tests - a wiki page with actual embedded hCards to try parsing.
• hCard advocacy - encourage others to use hCard
• hCard "to do" - jobs to do

The hCard specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.

• hCard brainstorming - brainstorms and other explorations relating to hCard.
  • hcard-parsing-brainstorming - brainstorming specific to parsing of hCard
  • geo brainstorming
• hCard feedback - general feedback (as opposed to specific issues).
• hCard issues - specific issues with the specification.
• vCard errata - corrections to the vCard specification, which underlies hCard.
• vCard suggestions - suggested improvements to the vCard specification.