hcard-ja
hCard
hCardはvCard (RFC2426) のプロパティと値を用い、セマンティックなXHTMLで人や会社、組織や場所を表現するシンプルなフォーマットです。hCardはmicroformatsのひとつであり、(X)HTMLやAtom、RSSやその他のXMLに埋め込むことができます。
hCardを利用してみたいですか?ではまず、hCard creatorを使い、コンタクト情報を公開してください。または、hCard authoring tipsを読み、あなたのコンタクトページをhCardでマークアップしてください。
hCard仕様書
- 謝辞
- 謝辞のセクションをご覧ください。
権利に関する情報は、著作権と特許のセクションをご覧ください。
はじめに
vCard (RFC2426) は、Appleのアドレスブック機能をはじめさまざまなところで実装され、広く使われているフォーマットです。
さて、多くのブロガーは、自分の名前を出し友人や家族のことを書いています。人に関するこれらの情報にすこし構造を加えるだけで、アグリゲーターやスパイダーがその情報を取得し、vCardへ自動的に変換しアプリケーションで利用することができます。
この仕様は、hCard というフォーマットを定義します。これはvCardのプロパティや値を、XTHMLでそのまま表現しようとするものです。ブロガーはhCardをWebページに埋め込み、CSSで思うようにデザインすることができます。また、hCardはアプリケーションが他のファイルを参照することなしに、そのページから情報を取り出すことを可能とします。
hCard creatorを使い、出てきたHTMLコードをblogやWebサイトに貼り付け、コンタクト情報を公開してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
フォーマット
基本情報
vCard (RFC2426) のプロパティ名や値が、hCardの基礎を構成します。
hCardは、vCardのオブジェクト/プロパティ名を小文字にしたものをclass属性の値として使用します。vCardオブジェクトの入れ子関係は、そのままXHTML要素の入れ子関係に置き換えられます。
ルートclass名
hCardのルートclass名は "vcard" です。"vcard" というclass名が指定された要素を、hCard と呼びます。
プロパティとサブプロパティ
hCardのプロパティは、hCard内の要素によって表されます。次にリストするプロパティをclass属性に指定することにより、プロパティを表現します。いくつかのプロパティはサブプロパティを持ちますが、これらはプロパティ要素の中にサブプロパティ要素を設け表現します。
プロパティリスト
hCardのプロパティは次の通りです。サブプロパティは括弧内に記述しています。
必須プロパティ
- fn
- n* (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)
任意プロパティ
- nickname, sort-string
- url, email (type, value), tel** (type, value)
- adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value), label
- geo (latitude, longitude), tz
- photo, logo, sound, bday
- title, role, org (organization-name, organization-unit)
- category, note
- class, key, mailer, uid, rev
プロパティについて
* 'n' プロパティは、'n' の省略ルールが適用できる場合は、任意 (OPTIONAL) プロパティとなります。
** tel - 電話番号は、E.123に従って記述することができます (MAY)。
複数のプロパティ
ひとつのhCardは、一つ以上の 'fn'、'n'、'bday'、'tz'、'geo'、'sort-string'、'uid'、'class' を持つことはありません。これらのプロパティが複数ある場合は、最初の値を残し、他の値を無視することが推奨されます。
他のプロパティは複数あっても構いません (MAY)。この場合、複数あるプロパティはその数だけ新しいインスタンスを作成します。
"Human readable" か "Machine readable" か
要素の内容のうち、人間に見えるテキスト情報が、そのプロパティの値を表します。しかし、いくつか例外が存在します。
もし <abbr>
要素がプロパティに用いられている場合、要素の内容ではなく <abbr>
要素の 'title
' 属性値がプロパティの値となります。要素の内容は、より人間にとって読みやすい値の表現となります。
もし <a>
要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります (MUST)。
- 'photo' プロパティと、他にURLを取るすべてのプロパティでは、
href="..."
属性の値がプロパティの値となります。 - その他のプロパティでは、要素の内容がプロパティの値となります。
もし <img>
要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります (MUST)。
- 'photo' プロパティと、他にURLを取るすべてのプロパティでは、
src="..."
属性の値がプロパティの値となります。 - その他のプロパティでは、
<img>
要素の 'alt
' 属性の値がプロパティの値となります。
もし <object>
要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります (MUST)。
- 'photo' プロパティと、他にURLを取るすべてのプロパティでは、
data="..."
属性の値がプロパティの値となります。 - その他のプロパティでは、要素の内容がプロパティの値となります。
値の抜粋
要素の一部だけがプロパティの値として当てはまるという場合があります。例えば、'tel' のように、サブタイプを持つようなプロパティです。このような場合、特別なclass名である "value
" を用い、プロパティの値として適切なものをマークアップします。家の電話番号をマークアップするhCardを例に取り説明しましょう。
vCard:
TEL;TYPE=HOME:+1.415.555.1212
hCard:
<span class="tel"> <span class="type">home</span>: <span class="value">+1.415.555.1212</span> </span>
このhCardは次のように表示されるでしょう。
home: +1.415.555.1212
プロパティの例外
vCardには、Webページの内容としてあまり意味をなさない、もしくは何らかのかたちですでに存在しているプロパティが存在しています。このセクションでは、そのようなプロパティに対し、何を行い、何を行わないかを説明します。
- vCardの NAME、PROFILE、SOURCE、PRODID、VERSION プロパティはRFC2426のセクション2.1.2、2.1.3、2.1.4、3.6.3、3.6.9で定義されていますが、hCardではこれらのプロパティを使ってはいけません (MUST NOT)。hCardを利用するものは、もしこれらのプロパティが使われていた場合、それらを無視する必要があります (MUST)。hCardからvCardへ変換するコンバーターは、これらのプロパティの代わりにhCardが埋め込まれているWebページの情報を用いて、これらのプロパティを埋めることになります。まず、NAMEプロパティは文書のタイトル ((X)HTML文書の場合、
<title>
要素) を用いることが推奨されます (SHOULD)。PROFILEの値には、RFC2426より "VCARD
" の値を使うことができます (MAY)。SOURCEプロパティには、ページのURLを用いることが推奨されます (SHOULD)。hCardをvCardに変換するサービスならば、そのパラメーターとしても用いることができるでしょう。PRODIDプロパティは、実際にvCardを出力するサービスやアプリケーションのみが記述するべきです (SHOULD)。同様に、そのようなアプリケーションのみが、RFC2426のセクション3.6.9.に倣い、VERSIONプロパティに "3.0" という値をつけるべきです (SHOULD)。
組織のコンタクト情報
もし、"FN" と "ORG" プロパティが同じ値を持っている場合 (多くの場合、これらは class="fn org" と同じ要素に記述されています)、そのhCardは会社や組織、場所のコンタクト情報を表すものとみなされます (SHOULD)。このとき、作成者は "N" プロパティを記述することはできない (MUST NOT)、もしくは、"" と、空文字列を記述する必要があります。このため、パーサは "N" プロパティの省略をふまえた対応が推奨されます (SHOULD)。この場合は、全ての "N" サブプロパティに空文字列があるものとみなします。
Implied "n" Optimization
vCardでは "N" プロパティの記述が必須となっています。ところが、vCard仕様書 (RFC2426) では、最後の方 (p.38) にある作者のvCardに "N" プロパティが含まれていません。この明らかな矛盾は、"FN" プロパティがこの仕様書のように、多くの場合において "N" プロパティの内容を暗示していると解釈すれば問題なくなります。というわけで、hCardではそのように規定します。
もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値がホワイトスペースで区切られた二つの単語のみで構成されており、さらに "N" プロパティが存在しない場合、"N" は "FN" プロパティの値から推測されます。もし "FN" が単語一つの場合は次の段落を、もし "FN" が三つ以上の単語である場合、作成者は "N" プロパティを明示的にマークアップする必要があります (MUST)。しかし、組織名の場合はこのルールに当てはまりません。この場合は組織のコンタクト情報で書かれているルールが適用されます。
- The content of "FN" is broken into two "words" separated by whitespace.
- The first word of the "FN" is interpreted as the "given-name" for the "N" property.
- The second/last word of the "FN" is interpreted as the "family-name" for the "N" property.
- Exception: If the first word ends in a "," comma OR if the second word is a single character (optionally followed by a period "."), then the first word (minus the comma at the end if any) is interpreted as the "family-name" and the second word is interpreted as the "given-name".
This allows simplification in the typical case of people stating:
- given-name (space) family-name
- family-name (comma) given-name
- family-name (comma) given-name-first-initial
- family-name (space) given-name-first-initial (optional period)
Implied "nickname" Optimization
Due to the prevalence of the use of nicknames/handles/usernames in actual content published on the Web (e.g. authors of reviews), hCard also has an implied "nickname" optimization to handle this.
Similar to the implied "n" optimization, if "FN" and "ORG" are not the same, and the value of the "FN" property is exactly one word, and there is no explicit "N" property, then:
- The content of the "FN" MUST be treated as a "nickname" property value.
- Parsers SHOULD handle the missing "N" property by implying empty values for all the "N" sub-properties.
Though parsers MUST follow the implied nickname optimization, publishers SHOULD explicitly indicate the "nickname" even in this case, e.g.:
<span class="vcard"> <span class="fn nickname">daveman692</span> </span>
The hCard MAY have additional explicit "nickname" property values in addition to the implied nickname.
Implied "organization-name" Optimization
The "ORG" property has two subproperties, organization-name and organization-unit. Very often authors only publish the organization-name. Thus if an "ORG" property has no "organization-name" inside it, then its entire contents MUST be treated as the "organization-name".
Tags as Categories
Categories in hCard MAY be represented by tags with rel-tag. When a category property is a rel-tag, the tag (as defined by rel-tag) is used for that category.
type subproperty values
The 'type' subproperty in particular takes different values depending on which property it is a subproperty of. These 'type' subproperty values are case-INSENSITIVE, meaning "Home" is the same as "home", as well as multivalued, e.g. a tel can be home and preferred:
vCard:
TEL;TYPE=HOME,PREF:+1.415.555.1212
hCard:
<span class="tel"><span class="type">Home</span> (<span class="type">pref</span>erred): <span class="value">+1.415.555.1212</span> </span>
This could be displayed as:
Home (preferred): +1.415.555.1212
The following lists are informative. See RFC2426 sections 3.2.1 ADR, 3.3.1 TEL, and 3.3.2 EMAIL respectively for normative type values. They are repeated here for convenience. Default type subproperty value(s) is(are) first in each list and indicated in ALL CAPS. types may be multivalued.
- adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
- tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, car, isdn, pcs
- email type: INTERNET, x400, pref, "other IANA registered address types"
XMDP Profile
See hcard-profile for the XMDP profile of hCard which contains the above complete list of properties, with references to their RFC2426 definitions.
Parsing Details
See hCard parsing.
Examples
This section is informative.
Sample vCard
Here is a sample vCard:
BEGIN:VCARD VERSION:3.0 N:Çelik;Tantek FN:Tantek Çelik URL:http://tantek.com/ ORG:Technorati END:VCARD
and an equivalent in hCard with various elements optimized appropriately. See hCard Example 1 for the derivation.
<div class="vcard"> <a class="url fn" href="http://tantek.com/">Tantek Çelik</a> <div class="org">Technorati</div> </div>
This hCard might be displayed as:
Tantek Çelik
Technorati
Note: The version information is unnecessary in hCard markup directly since the version will be defined by the profile of hCard that is used/referred to in the 'profile' attribute of the <head> element.
Live example
Here are the WikiMedia Foundation's contact details, as a live hCard which will be detected, on this page, by microformat parsing tools:
work
The mark-up (wrapped, and emboldening omitted, for clarity) used is:
<div class="vcard"> <div class="fn org">Wikimedia Foundation Inc.</div> <div class="adr"> <span class="type">work</span> <div class="street-address">200 2nd Ave. South #358</div> <div> <span class="locality">St. Petersburg</span> <abbr class="region" title="Florida">FL</abbr> <span class="postal-code">33701-4313</span> </div> <div class="country-name">USA</div> </div> <div>Phone: <span class="tel"><span class="type">work</span>+1-727-231-0101</span></div> <div>Email: <span class="email">info@wikimedia.org</span></div> <div> <span class="tel"><span class="type">Fax</span>: <span class="value">+1-727-258-0207</span></span> </div> </div>
More Examples
See hCard examples for more examples, including all examples from vCard RFC2426 converted into hCard.
Buttons
You can use these buttons on pages with hCards. See buttons#hCard for any recent additions.
(mirror:
)
- CSS-powered button, as evidenced at microformat badges @ re-run
Examples in the wild
This section is informative. The number of hCard examples in the wild has expanded far beyond the capacity of being kept inline in this specification. They have been moved to a separate page.
See hCard Examples in the wild.
Implementations
This section is informative. The number of hCard implementations has also expanded beyond the capacity of keeping them inline. They have been moved to a separate page.
Copyright
Per the public domain release on the authors' user pages (Tantek Çelik, Brian Suda) this specification is released into the public domain.
Public Domain Contribution Requirement. Since the author(s) released this work into the public domain, in order to maintain this work's public domain status, all contributors to this page agree to release their contributions to this page to the public domain as well. Contributors may indicate their agreement by adding the public domain release template to their user page per the Voluntary Public Domain Declarations instructions. Unreleased contributions may be reverted/removed.
Patents
This specification is subject to a royalty free patent policy, e.g. per the W3C Patent Policy, and IETF RFC3667 & RFC3668.
References
Normative References
- XHTML 1.0 SE
- vCard RFC2426
- ITU recommendation E.123 format of telephone numbers (chargeable document)
- RFC 2119
Informative References
- hCard history
- X.520 in Postscript (HTMLization courtesy of Google Cache) - vCard refers to ROLE as being "based on the X.520 Business Category explanatory attribute".
- HTML reformatted version of RFC2426
- CSS1
- XHTML 1.1
- Wikipedia summary of ITU-T Recommendation E.123 - for "TEL" values.
- Internet Mail Consortium Personal Data Interchange vCard and vCalendar
- ISO8601
Specifications That Use hCard
Similar Work
Inspiration and Acknowledgments
Thanks to: my good friend Vadim who introduced me to vCard many years ago, and if I'd only paid more attention then, perhaps I could have helped a lot of people avoid wasting a lot of time reinventing various standards wheels.
Notes on derivation from vCard
This section is informative.
More Semantic Equivalents
For some properties there are HTML elements which better match and convey their semantics. The following properties SHOULD be encoded with the following (X)HTML:
URL
in vCard becomes<a class="url" href="...">...</a>
inside the element withclass="vcard"
in hCard.- Similarly,
EMAIL
in vCard becomes<a class="email" href="mailto:...">...</a>
PHOTO
in vCard becomes<img class="photo" src="..." alt="Photo of ..." />
or<object class="photo" data="..." type="...">Photo of ...</object>
UID
in vCard simply becomes another semantic applied to a specific URL (or EMAIL) for an hCard.
Singular and Plural derivations
The lists of singular and plural properties have been derived by analyzing the semantics of the individual properties in vCard RFC2426 and determining logically that they MUST be singular per their semantics. See hcard-singular-properties for explanations.
Plural Properties Singularized
Since plural property names become their singular equivalents, even if the original plural property permitted only a single value with multiple components, those multiple components are represented each with their own singularly named property and the the property is effectively multivalued and subject to the above treatment of multivalued properties.
Further Reading
- Digital Web Magazine: Microformats Primer by Garrett Dimon has a good intro to hCard
- Practical Microformats with hCard by Drew McLellan
- Local Search Engine Optimization using Microformats by Chris Silver Smith
- Andrew D. Hume has written a blog post on usable microformats which discusses hCard
- Jesse Skinner's introduction to hCard
- Shaun Shull's great post on How Microformats Affect SEO, including his hCard as an example.
- 24 Ways: Styling hCards with CSS A 24 Ways article - John Allsopp on styling hCard using CSS
- See also blogs discussing this page and the hCard tag
- RFC 4770 - Extensions for Instant Messaging
Related Pages
- 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.